home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 739 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.7 KB
  1. Path: solon.com!not-for-mail
  2. From: spc@gate.net (Sean 'Captain Napalm' Conner)
  3. Newsgroups: comp.std.c,comp.lang.c.moderated
  4. Subject: Re: printf() format extensions - looking for beta testers...
  5. Date: 14 Apr 1996 10:54:50 -0500
  6. Organization: CyberGate, Inc.
  7. Sender: clc@solutions.solon.com
  8. Approved: clc@solutions.solon.com
  9. Message-ID: <4kr74a$k8o@solutions.solon.com>
  10. References: <4kll9l$o5h@solutions.solon.com> <4kobun$8i2@solutions.solon.com> <4koecq$8up@solutions.solon.com>
  11. NNTP-Posting-Host: solutions.solon.com
  12.  
  13. In article <4koecq$8up@solutions.solon.com> seebs@solon.com writes:
  14. >In article <4kobun$8i2@solutions.solon.com>,
  15. >Sean 'Captain Napalm' Conner <spc@gate.net> wrote:
  16. >>  But there is a potential problem with doing this.  What if you use a
  17. >>pre-compiled module that has extended printf(), say, using '%#' (unbeknownst
  18. >>to you, the documentation may be a bit lax (happens enough)).  What happens
  19. >>when you try to extend printf() using '%#'?  With possible different
  20. >>semantics (different type, say)?
  21. >
  22. >That's why mine is not like the plan 9 fmtinstall().  In my current design,
  23. >assuming that we have
  24. >    typedef int (*fmtconv)();
  25.  
  26.   [ information about fmtconv() deleted ]
  27.  
  28. >This has been described as overengineering, but is there for precisely
  29. >that reason.
  30. >
  31.   To me it sounds horribly complicated and overengineered.  Simplify it 8-)
  32.  
  33. >%# would be a poor choice; the conversion func for %# is one which returns
  34. >a magic cookie to set the alternate format flag.  :)
  35. >
  36.   Oh.  Ah.  Well.  What IS available?
  37.  
  38. >>  -spc (Or does your printf() report a redefinition error?)
  39. >
  40. >Nope.
  41. >
  42. >I'm also considering the sfio magic of
  43. >    %(foo)
  44. >calling a conversion func attached to the string "foo".  This seems
  45. >frivolous for small apps, but if you look at a POSIX system, with
  46. >N+1 magic types like uid_t and gid_t, it might be useful.
  47. >
  48. >The problem is mostly coming up with a consistent way of parsing
  49. >things such that no currently standardized call to printf will change
  50. >behavior unless you've done something else (like call format()) which
  51. >is not standardized.
  52. >
  53.   Well, why not change the approach?  The current printf() will accept a
  54. line such as:
  55.  
  56.         printf("%*s",someint,somestring);
  57.  
  58.   To allow variable widths to be specified.  Why not extend that and pass in
  59. the function pointers?  Something like:
  60.  
  61.         printf("%p@",myfunctptr,myptrtype);
  62.  
  63.   Where '@' specifies a format function, and the letter before it declares
  64. the type using a single letter specification:
  65.  
  66.         c    - char
  67.         s    - short
  68.         i    - int
  69.         l    - long
  70.         f    - float
  71.         d    - double
  72.  
  73.   With the following modifiers:
  74.  
  75.         p    - pointer (if alone, void *)
  76.         u    - unsigned
  77.     
  78.   Less chance of clashes, and more flexible I feel.
  79.  
  80.   -spc (Remember the KISS principle ... )
  81.